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PREFACE 


Intercomm is a state-of-the-art teleprocessing monitor system executing on the 
IBM System/390 family of computers and operating under the control of IBM Operating 
Systems (ESA and OS/390). Intercomm monitors the transmission of messages to and 
from terminals, concurrent message processing, centralized access to |/O files, and the 
routine utility operations of editing input messages and formatting output messages, as 
required. 


The Intercomm product is under continual development designed to keep the 
system at the forefront of computer technology. This document describes the incremental 
enhancements that have been added to our latest release, Release 11. This release 
represents a major technology upgrade, incorporating many new features that improve 
system reliability, ease on-line programming requirements, and facilitate maintenance and 
installation. 


This manual provides a synopsis of each of the Release 11 features. While every 
attempt has been made to ensure the technical accuracy of data in this document, the 
reader should refer to the various system technical documents for feature implementation 
specifics. 


It is assumed the reader has a basic familiarity with the Intercomm Teleprocessing 
Monitor System, its features and tables. 
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Chapter 1 


INTRODUCTION 


Release 11 of Intercomm contains extensive and significant improvements, 
affecting many areas of the Intercomm teleprocessing monitor. Among the Release 11 
features are: 

e Incorporation of Release 10 Experimental SM’s developed post SM Level 2300 

e Addition of written and telephoned requests from users 

e Incorporation of funded development enhancements 

e New options and features 

e Statistics gathering/reporting enhancements 

e Performance and reliability improvements 

e Debugging aids 

e Eased restrictions 

e On-line system maintenance and display command upgrades 

e Virtual storage constraint relief 

Testing procedures for Release 11 included both extensive in-house testing and 
field Beta testing at several user sites which were chosen for the variety of options to be 
tested and representative operating systems in use. As a result of this procedure, users 
are assured of a stable release, and that upgrading to Release 11 can be accomplished 
smoothly. 

In the following chapter, the Release 11 enhancements are described in detail, 
along with the accompanying documentation upgrades, and conversion considerations for 


current users of Intercomm. 


Many of the enhancements are in production at one or more Release 10 sites. All 
of the enhancements are in production at one of the Release 11 Beta test sites. 


The lowest IBM Operating System configuration level supported by this release of 
Intercomm is ESA 4.3 with the new version of the TIME macro (having the LINKAGE and 
DATETYPE parameters), DFSMS 1.2, and VTAM 3.4. HLASM (High-Level Assembler) 
and the DFSMS Binder are also required for assemblies and linkedits of Intercomm 
modules. 
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RELEASE 11 FEATURES 


2.1 FEATURE CATEGORIES 


For convenience and planning purposes, the Release 11 enhancements and new 
features have been grouped into the following categories: 


e General system enhancements 

e General system improvements 

e User Exit changes 

e Desupported facilities 

e User program processing optimizations 

e Virtual Storage constraint relief 

e Statistics gathering and system display/report upgrades 

e VTAM Front End changes 

e System control command changes and additions. 

e ESS (Extended Security System) enhancements 

For each of these categories, the individual items will be described together with 
the impact, if any, on system externals. Some of these improvements were originally 
available and tested as Experimental SMs. However, the interrelationship with other 


enhancements necessitated incorporation and modification of such code into official 
Release 11. 
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2.2 


Release 11 Features 


GENERAL SYSTEM ENHANCEMENTS 


System enhancements described in detail in the following subsections are: J 


Year 2000 compliance 

OS/390 compatibility 

Storage Management reliability checking and recovery 

31-Amode dynamic storage and pools support 

Dynamic LU support 

Procs using Assembler H upgraded to Hi-Level Assembler (HLASM) 
Procs using the Linkage Editor revised to use the Binder 

High thread count warning of system slowdown 


BMN back-off (to Release 9 2-byte field) automatic installation generation, if 
desired 


Multiregion now supports multiple MRS systems in one CPU (LPAR) 
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2.2.1 Year 2000 Compliance 


The following changes were made to provide Intercomm Year 2000 compliance: 


e Modify INTTIME, GETDATE macros for 4-digit year: return date as ccyyddds packed 
field. Both macros are downward compatible to R10, except that the date in R1 is 
yyyyddds, not OOyyddds. Note that GETDATE uses the value in CVTDATE and 
modifies the high-byte, and has been replaced in on-line modules with INTTIME. 


e In the INTTIME-generated TIMESECT Csect, simulate the ESA TIME macro with 
LINKAGE=SYSTEM and DATETYPE=YYYYDDD, and DEC (default time) or BIN or 


MIC to get the date and then convert it to a packed field to return in R1, and load the 
time to RO if DEC (default) or BIN option used on the INTTIME macro, or pass back 
MIC time, if requested. This will allow date/time simulation software (such as 
lsogon’s TICTOC) to be used for testing. Also in TIMESECT, use STCK to get the 
TU time if requested (only used by Dispatcher and modules looking at Dispatcher 
WQE’s) and return the result in RO (LINKAGE=SYSTEM version of ESA TIME macro 
does not support the TU parameter), and return the 4-digit year in R1. Note that 
STCK as a parameter for the INTTIME macro is not supported (not needed). 


e Replace TIME (LINKAGE=SVC) with INTTIME in on-line modules where date needed: 
BTAMSIM, DDQMOD, LOGINPUT, PMIOUTPT, PMISIGN, SIM3270. 


e Revise PMIDATER to put 5-byte packed Ommddyyyys in new SPADATEC field in 
SPA: (replaces old V(PMIDATER) - not needed) and to correct leap-year recognition, 
change STARTUP3 to use V(PMIDATER) and move the call earlier so SPADATE 
(Ommddyys) and SPADATEC are set earlier in startup. 


e Revise the Dispatcher (IJKDSP01) to immediately recognize that midnight has 
passed, and then to immediately call (not dispatch) PMIDATER to update SPADATE 
and SPADATEC. 


e Change modules now_using SPADATE to use SPADATEC: SSRPT, SUBRPT, 
USRSTART, USRCLOSE (do not change INTDEQ30 - Data Entry feature no longer 
used). 


e Fix on-line system _report/statistics modules to use SPADATEC: TDUMP, IJKTRACE, 
INTSTS, IXFRPTO1, RMTRACE. 


e Fix SYSCNTL: SCTLSTDUMP$nnn$TID display - change yy.ddd to yyyy.ddd in 


header. 
e Fix POOLDUMP: add time/date stamp to header, process a line count (60 per page). 


e Add date to TALY command TIME and REGION trailer line (fix TALLY and 
RPT00043). 
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e Modify utility/report programs to use TIME macro with LLNKAGE=SYSTEM to get time 
and date for report header - LOGPRINT, DDQPRT, PMILOAD, SFDMPRST (add 
header). 


e Modify ESS modules for 4-digit years, provide update utility - see Section 2.11 - ESS 
(Extended Security System) Enhancements. 


e Do not change size of MSGHYR in message header (LOGPUT), do not change text of 
PMIWTO message FR999I (RECREATION START POINT ...... ). 


e Check programs referencing MSGHYR: IXFCREAT, IXFSNAPL, LOGMERGE - no 
change needed. 


e Ensure no problem with Checkpoint/Message Restart across millenium: CHECKPTS, 
LOGPROC, RESTORE3(change TIME macro to INTTIME). 


e Ensure batch programs referencing Log fixed for date comparisons over millenium 
wrap from ’99 to '00: LOGPRINT, LOGMERGE, IXFCREAT, ICOMFEOF. 


e Fix Log Analysis programs for report date, leap years, and millenium wrap: JULIAND, 
LOGANAL, LOGANE15, LOGRESP, LOGOPTNS (internal macro). 


e For SPINOFF and FASTSNAP - do not change date field in snap data set name (now 
yyddd) as it may affect user data set scan programs (to delete expired snaps), and/or 


user data set name modifications. 


e For MMUCSDATE command: note that the date is taken from &SYSDATE generated 
at Assembly time. Because generating a 4-digit year would require reassembly, link, 
then load of all map groups for all systems (regions), the date is modified in the 
subsystem (MMUCOMM) to display a 4-digit year. 


e Update ASME (IAIM...) Cross-reference modules for 4-digit year in reports. (To be 
supplied with first SM tape.) 


NOTE: starting and ending date parameters for LOGPRINT and LOGANAL are in the 
form yyddd, as previously. 


Documentation Changes: Basic System Macros 
Operating Reference Manual 
system Control Commands 


File Recovery Users Guide 
ASME Users Guide 


New External Options: None. Review all user programs issuing INTTIME or 
GETDATE macro for impact of 4-digit year. 


Installation: Automatic (ensure new Intercomm version of internal 


TIMESECT Csect is in the linkedit before user programs 
issuing INTTIME macro which were not reassembled). 
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| 2.2.2 OS/390 Compatibility 


The following changes and enhancements have been made to provide OS/390 
compliance and compatibility: 


e Supplied JCL procs have been changed, as applicable, to execute the HLASM (High- 
Level) Assembler called ASMAS90, as described in Section 2.2.6. 


e Supplied JCL procs have been changed to execute the DFSMS Binder (LINKEDIT), 
as applicable. Also, AM and RM parameters have been added to specify execution 
AMODE and RMODE of the load module, if needed. See Section 2.2.6.1 


e Modules have been corrected, where possible, to provide a return code of O under 
ASMASO. Exceptions (which have a return code of 4 but execute correctly) include 
IXFDYNAM, IXFHNDO1, READBACK, INTSECO2, and several Log Analysis modules. 


e The requirement during installation to modify the IBM SPLEVEL macro (to 
generate the MVS/370 version of some IBM macros during assembly of certain 
Intercomm modules) has been removed. Job 06, (formerly generated by the 
ICOMGEN macro for the installation job stream to copy the SPLEVEL macro to 

___SYMLIB) has been replaced to produce the BMN back-off JCL stream (if desired) - ___ 


see Section 2.2.8. 


e When using DFSMS with file access method modules moved above the 16M line, a 
SOC4 can occur if the caller’s save area address in register 13 does not have X’00’ in 
the high-order byte. Intercomm modules which used R13 as a base register and local 
save area address (via a BAL instruction) have been corrected to prevent this 
ed problem. 


e Under ESA V5.2.2 and OS/390, subtasks can execute synchronously with main tasks, 
therefore, the interrelationship between the Dispatcher (IJKDSP01), Snap Processing 
(PMISNAP1), and the system execution timeout/loop-detection subtask (IJKTLOOP) 
has been corrected to prevent potential problems in this area of the system. 


e Because subtasks can now execute concurrently with main tasks, ICOMCESD has 
been modified to be able to directly call INTSORT when linked with ICOMCESD. This 
link is required (generated by ICOMGEN installation macro) to prevent an abend at 
startup if the INTSORT in the main Intercomm task is called by the subtask. 
INTSORT is serially reusable, but not reentrant. ICOMCESD is attached as a subtask 
at startup by ICOMDYNL (which must be in the Intercomm link) to build the 
name/address location table above the 16M line which is used by the LOC[ATE] 
parameter of the SCTL command, and by dynamic linkedit processing (if needed). 


e |BM’s Language Environment is not supported. Therefore, when upgrading to/within 
OS/390, ensure the pre-LE MVS high-level system language libraries are kept for 
compiles and link-edits, and that the associated system run-time library is in the 
STEPLIB concatenation for Intercomm execution. 


Documentation Changes: Operating Reference Manual 
Installation Guide 


C New External Options: None 
Installation: Automatic (ensure ICOMCESD linked with INTSORT). 
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2.2.3 Storage Management Reliability Checking and Recovery 


MANAGER has been substantially rewritten to provide pool header integrity 
checking and overlay recovery. This enhancement is designed to prevent unexpected 
program checks in MANAGER and to provide easier debugging of a core (pool header) 
overlay problem. In addition, RMINTEG processing has been redesigned to substantially 
reduce processing overhead and to recover an overlaid header if possible, without 
abending the system. 


For both 24 and 31-Amode pools, MANAGER validates the 8-byte pool header for 
STORAGE (first free block header) and STORFREE requests. If an invalid header is 
found, revised message RMO12A giving the bad header address and a snap is issued. 
On a STORAGE, the pointer in ICOMCHN to the free block chain is zeroed (free blocks 
for that pool size are Jost) and a GETMAIN is done. On a STORFREE, the header is 
corrected if only the first word is overlaid, so that freeing of the pool block can be 
attempted. Otherwise, the block is not returned to the free chain, only the RCB is freed. 
Before return to the caller, a Thread Dump is produced (current owner of previous pool 
block may have caused the overlay). 


RMINTEG processing has been completely redesigned to only validate the header 
of the next pool block on each STORFREE from the 24-Amode pools. If that header is 
invalid, it is probable that the STORFREE issuer has caused the overlay. RMINTEG is 
not called if the header of the block being freed is overlaid and cannot be recovered. 
When an invalid neighbor pool block header is found, a message (revised RMO22A) and 
debugging snap and Thread Dump is issued. RMINTEG then resets the overlaid header 
for future use, and returns to STORFREE processing. 


TRAP processing has been optimized for header and chain checking of each pool 
size group of blocks in the 24-Amode pools. TRAP has also been modified to allow the 
user to easily insert code to test for a specific overlay string and/or to make a simple 
change to only test the headers of a specific pool size. See the comments at the 
beginning of the module for implementation directions. TRAP also now uses standard 
abend processing after disabling itself. 


Documentation Changes: Basic System Macros 
Installation Guide 


Operating Reference Manual 
Messages and Codes 
Assembler Lanquage Programmers Guide 


New External Options: RMINTEG processing code is generated in MANAGER if its 
global is set to 1 in SETGLOBE (recommended). The 
processing must then be activated via the STRT command 
in each region where it is desired (add to user startup 
processing for each test region). 


Installation: Reassembly of the Intercomm 24-Amode pools is required: 
ensure that the only Csect statement is for the COREACCT 
Csect and is placed before the COREACCT macro (before 
the ICOMPOOL macros). If linkedit ordering is used, 
ensure the ICOMCHN, ICOMPOOL, POOLEND Csects are 
together in exactly that order (if pools in Intercomm linkedit). 
Relink dynamically loaded user Assembler programs with 
Release 11 INTLOAD. 
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2.2.4 31-Amode Dynamic Storage and Pools Support 


To provide for Intercomm and user program requests for dynamic storage above 
the 16M line, and to have those requests tracked via RCBs, the LOC=ANY/BELOW 
parameter for the STORAGE macro has been provided. Coding LOC=ANY will cause a 
31-Amode (31-bit) storage address to be returned. To address the returned storage, the 
calling program must then execute in 31-Amode (use XASWITCH macro to flip modes if 
residing in (or loaded into) 24-Amode memory, and be sure to flip back to 24-Amode 
before issuing other macros or calling other programs/service routines). If LOC=ANY, the 
LIST parameter may be used, but it must point to 24-Amode storage. The ADDR 
parameter (if used) may point to 24-Amode (hi-byte must be zero) or 31-Amode storage. 


The STORFREE, PASS, and CATCH macro entry-points, to the Resource 
Management module MANAGER, have also been modified to process 31-Amode 
addresses. The issuing user must ensure that the high-order byte of a 24-bit address 
passed to these entry-points is zero. The entry-points will first search RCBs for 31-bit 
core addresses if the high-order byte of the address is non-zero. PASS and CATCH 
entry-points will then do standard 24-bit address processing (after first clearing the high- 
order byte of the passed address). STORFREE will issue a message (RMO013A) and 
force a program check if no RCB match for the address with a non-zero high-order byte is 
found - it will not revert to standard 24-bit processing. The SPA parameter may now be 
used on STORAGE and STORFREE issued in 31-Amode, and the SPAEXT parameter 
may be used on PASS and CATCH issued in 31-Amode. MANAGER returns to the caller 
in the caller's Amode. 


This Support requires RCBs to ensure correct processing of 31-bit addresses, 
therefore the &RM global has been removed from INTGLOBE and SETGLOBE (RCB 
Table always acquired). The &RMPOOLS global has also been removed (not needed). 


LOC=ANY (for 31-bit dynamic storage addresses via GETMAIN) and entry in 31- 
Amode for STORAGE and STORFREE requests is also supported in batch mode 
processing for calling programs linked with the !ntercomm BATCHPAK interface routine. 


MANAGER has also been revised to support a 31-Amode pools module (as for 
24-Amode pools) to satisfy STORAGE requests with LOC=ANY for which a GETMAIN is 
not forced (via a SP (non-zero) or BOUND=PAGE or POOLS=NO parameter). If used, 
the pools module is coded the same as for 24-Amode pools (see provided sample 
IC31PLO00 on SYMREL), and must have the name IC31PLxx, because it is dynamically 
loaded at startup. The xx suffix is defined on the SPALIST macro via new parameter 
IC31PL=xx (default is NO indicating no 31-Amode pools to be used for the region). 
IC31PLxx must be linked with AMODE=31 and RMODE=ANY so it is loaded above the 
16M line by POOLSTRT which must be included in the Intercomm linkedit to load pools. 


POOLDUMP has been optimized to reduce the number of printed lines, and 
revised to process 31-Amode pools (if defined). RMTRACE has been rewritten to also 
provide core use statistics for 31-Amode pools (if defined) in the same manner as for 24- 
Amode pools. To reduce the number of printed lines, concurrency lines are omitted for 
COREACCT size ranges for which no STORAGE requests have been issued. TDUMP 
(Thread Resource Dump report) and SCTLSTDUMP display processing have been 
modified to report 31-Amode pool storage requests as for 24-Amode pools. 


INTTABLE has been revised to use the 31-Amode pools, if present, for Table (and 


Page) Facility processing, except if the TABSP parameter is coded on the SPALIST 
macro. 
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A TRAP31 version of the revised TRAP (see Section 2.2.3) for the 31-Amode 
pools has also been created (both modules may not be used in the same link). J 


Documentation Changes: 


New External Options: 


Installation: 


Basic System Macros 

Operating Reference Manual 

Messages and Codes 

Installation Guide 

Assembler Lanquage Programmers Guide 
Table Facility 


SPALIST macro, 1C31PL=xx/NO. 

ICOMGEN macro, DYNPOOL=P31, and ICOMLINK macro, 
DYNPOOL=P31 to indicate only 31-Amode pools to be 
loaded (code YES to load both 24-Amode and 31-Amode 
(if defined) pools modules). 

When executing in 31-Amode, the SPA parameter may be 
used on the STORAGE and STORFREE macros, and the 
SPAEXT parameter on PASS and CATCH macros (even if 
executed by a dynamically loaded 31-Amode program 
linked with INTLOAD). 


If desired, modify the supplied 1C31PLO0 module (put it in 
SYMUSR) to define 31-Amode pools, then reassemble and 
link it with AMODE=31 and RMODE=ANY (see Section 
2.2.6) to a library in the STEPLIB concatenation for 
Intercomm execution. Code additional IC31PLxx modules 
for other regions, as desired. 

Code the IC31PL parameter on the corresponding SPALIST wi 
macro for each region to have 31-Amode pools, 

and add POOLSTRT to each linkedit. 

Link batch program with BATCHPAK to use the STORAGE: 
macro with LOC=ANY. 
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2.2.9 Dynamic LU Support 


In order to reduce the size of the VIAM Network Table, this major enhancement 
allows for a pool of ‘dynamic’ LUNIT’s to be used for random Logons of input/output LU’s 
(CRT’s) defined only in the Network VTIDTAB Table (LSB and CSB parameters have 
been added to the VIIDTAB macro for ‘dynamic’ LU-ids). LUNIT’s from the pool can also 
be acquired for sporadically used ‘shared’ printers (output-only devices) defined only via 
VTIDTAB macros. An optional ‘printer’ timeout (VTLSB macro, TIMEOUT parameter) 
provides for flushing queued messages and freeing the ‘dynamic’ LUNIT (after the 
defined timeout elapses without an intervening successful logon) when the printer cannot 
be acquired or is SPLU’d (internally or dynamically) due to transmission errors. Code a 
reasonable timeout value to allow the user time to discover that output is not being printed 
and to then correct the problem with the printer, if possible. Thus, attrition of available 
‘dynamic’ LUNIT’s is prevented. If no messages are queued for a ‘dynamic’ logged-on 
printer when it is SPLU’d, it is immediately freed from the ‘dynamic’ LUNIT. The ‘dynamic’ 
LUNIT for a CRT is freed when the LU logs off (any queued messages are flushed 
automatically), therefore a STLU command cannot be used for a ‘dynamic’ CRT. Using a 
‘dynamic’ LUNIT pool permits a Network Table size reduction of 50% to 75%, 
especially if more than 1000 LUNIT’s are currently defined. All ‘dynamic’ VTAM LU’s 
which may log on to, or be acquired by, Intercomm, must be defined via VTIDTAB 
macros, therefore, the security feature of not allowing ‘foreign’ logons (VTAM-id not in 
VTIDTABL) is preserved. 


The control terminal (and its alternate), the CPU Console, LUNIT’s which require 
ACQ=YES, LUNIT’s requiring autoup processing (UPINTV parameter coded), LU’s which 
are logged on most of the day, and printers receiving a lot of output (or for which output is 
critical), must remain as static LUNIT’s. Alternate terminal definitions are not supported 
for ‘dynamic’ LU’s, and if required, such LUNIT’s must also remain static. Static LUNIT’s 
must be coded in the Network Table before the LUNIT macro defining the ‘dynamic’ pool 
The ‘dynamic pool’ LUNIT must be coded last (before the PMISTOP macro), and may 
only have message queuing parameters (which must be large enough to handle a 
‘dynamic’ printer queue), and must have the DYN=(nnnn,x) parameter, where nnnn 
defines the number (up to 9999) of ‘dynamic’ LU’s in the pool, and x defines the 
alphabetic prefix (first character) of the internally-generated LUNIT’s 5-character 
Intercomm names (in the range x0001 to xnnnn). Choose a ‘prefix’ value for x that will 
not conflict with existing Intercomm ‘terminal-id’ names. The size of the ‘dynamic’ LUNIT 
pool (value of nnnn) should be from one/sixth to one/half the current number of defined 
LUNIT’s, or be the current value for SNMAX on the VCT macro (if at least one/half less 
than the total defined LUNIT’s). See also the paragraphs on the SNMAX parameter, in 
relation to internal VTAM control block tables in Section 2.7, and in relation to the 
modified VTISTSTOT command (VTST display total lines) response in Section 2.8. 


To indicate that a ‘dynamic’ LUNIT pool and ‘dynamic’ VTIDTAB entries are 
present, a new parameter DYNLUS=YES must be coded on the VCT macro preceding 
LUNIT definitions. For formerly static LUNIT’s to be converted to ‘dynamic’ VTIDTAB 
entries, move the LSB and CSB parameters to the associated VTIDTAB macro. Code all 
VTCSB-eligible parameters (such as CRT=YES, CONV=YES, the MRPASSW parameter, 
etc.) on the associated VTCSB macro only. This may require adding more VTCSB 
macros to handle different AIDGRP, LOCK, and/or MRPASSW parameter combinations. 
Printers which use the pool must be defined as ‘shared’ via the associated VILSB macro 
(see SNA Terminal Support Guide) so that they are assigned to a ‘dynamic’ LUNIT, and a 
SIMLOGON is attempted to acquire the LU, when the first message is queued. Also add 
the TIMEOUT parameter on the associated VTLSB for those printers. 
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Because the LSB and CSB parameters must be coded on the VTIDTAB macros 
for ‘dynamic’ LU’s, the VTIDTAB table must be in the Network Table (after the PMISTOP 
macro delimiting the LUNIT entries). If DYNLUS=YES is coded on the VCT macro, then 
all VTIDTAB entries are internally expanded from 16 bytes to 32 bytes (vs. 208 bytes if an 
LU is defined as a static LUNIT with NUMCL=2). VTIDTAB entries for ‘dynamic’ LU’s 
contain offsets to the associated VTLSB and VTCSB macro definitions, requiring that the 
VTIDTAB macros be in the Network Table. For static LUNIT’s, the VTID parameter may 
still be coded. If VTID is not coded on the static LUNIT’s, then VTIDTAB entries for static 
LUNIT’s must precede those for ‘dynamic’ entries in the Network Tabie. To indicate the 
start of ‘dynamic’ VTIDTAB entries, a special VTIDTAB macro with only the new 
parameter DYN=YES must be coded. As before, the last ‘dynamic’ VTIDTAB macro 
entry must be followed by a VIIDTAB macro with only the parameter LAST=YES (to 
generate the internal indices for all static and dynamic VTIDTAB entries). To allow for 
coding the new LSB and CSB parameters on the same line, the ICOMIDS and VTAMIDS 
parameters have been shortened to ICID and VTID, respectively. The short versions can 
also be used for static LU VTIDTAB entries (except for the CPU Console, for which no 
VTIDTAB macro may be coded), if desired. 


A sample VTAM Network Table called DYNSAMP has been provided on the 
Release 11 SYMREL, to illustrate new parameters for defining ‘dynamic’ LU’s, and coding 
of all associated macros. 


This enhancement has been carefully designed to make the use of ‘dynamic’ 
LU’s transparent to the terminal user and to programmers. The MSGHTID field in 
input messages will have the ICID associated with a VTID at logon, as for static LU’s, and 
the name in MSGHTID in output messages will be used to find the associated ‘dynamic’ 
LUNIT for output message queuing. Command processing has been upgraded to 
account for ‘dynamic’ LU’s, but will not display unassigned ‘dynamic’ LUNIT’s, unless one 
of them is specifically requested. Assigned ‘dynamic’ LUNIT’s will have the name, status, 
and characteristics of the associated ‘dynamic’ VTIDTAB entry. All commands which 
apply to static LUNIT’s can also be used for ‘dynamic’ LU’s. For example, a 
SPLU$...SDEACT for an LU will be flagged in the ‘dynamic’ VTIDTAB entry (if the entry is 
not currently assigned to a dynamic LUNIT) or will be flagged in the assigned dynamic 
LUNIT entry (and transferred to the ‘dynamic’ VTIDTAB entry when the LUNIT is 
unassigned), as applicable. 


The major difference is that messages cannot be queued for an unassigned CRT, 
nor for any unassigned ‘dynamic’ VTIDTAB entry which has been deactivated. There is 
no LUNIT with queuing contro! blocks available while the entry is unassigned, therefore 
the messages will be rejected (flushed). However, the requirement to define ‘dynamic’ 
printers as ‘shared’ allows for assigning a ‘dynamic’ LUNIT when the first message is 
queued, as long as the VTIDTAB entry for MSGHTID remains active (Logons allowed). 
As before, messages to be queued for an unknown LU (not found in either static LUNIT 
nor VTIDTAB entries) will be rejected. A STLU command for a down unassigned 
‘dynamic’ VTIDTAB entry will reactivate it (ACQ parameter ignored if entered). The new 
DEACT option for the VITST command will display down ‘dynamic’ VTIDTAB entries, as 
well as down static LUNIT’s and down assigned ‘dynamic’ LUNIT’s. 


The supplied user exit LUCUR for VTAM HALT (SPLU$...SHALT) processing has 
been modified to also process ‘dynamic’ LUNIT’s (flush all CRT queues at logoff, initiate 
timeout (if any) for non-CRT ‘dynamic’ devices), even if ESS (Extended Security System) 
is not used in the region. The advantage of the timeout for ‘dynamic’ printers is that 
operator intervention (to flush queued messages after SPLU/logon failure) is no longer 
needed, and messages which will never be sent will eventually be flushed automatically. 
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Broadcast message processing will skip a terminal-id in the group which is not 
logged on if the ‘terminal’ is a ‘dynamic’ VTIDTAB entry. Fast message switch to a 
‘dynamic’ CRT terminal which is not logged on will be discarded. Do not code Station 
Table entries for the dynamic LUNIT pool names (never needed). Generic entries for 
static LUNIT’s, and for ‘dynamic’ VTIDTAB entries, may be used in the Station Table - 
see Section 2.4.3. 


See also Section 2.8 on new ‘dynamic’ LUNIT pool usage statistics (via 
VTST$TOT command) for tuning the size of the pool, Section 2.9 on general VTAM Front 
End enhancements, and Section 2.10 for TALY and Front End command enhancements. 


A new Dsect (VTIDTABD) has been created to describe the expanded VTIDTAB 
entries, including new fields and flag settings. 


Documentation Changes: SNA Terminal Support Guide 
Messages and Codes 
system Control Commands 


New External Options: VCT macro, DYNLUS=YES/NO. 
LUNIT macro, revised DYN=(nnnn,x) parameter. 
VTLSB macro, TIMEOUT=nnnn (seconds) parameter to 
define when messages for a down DLU printer should be 
flushed so the ‘dynamic’ LUNIT can be released. 
VTIDTAB macro: ICID, VTID, CSB and LSB parameters to 
define dynamic VTIDTAB entries to use the DLU pool. 
VTIDTAB macro, DYN=YES to indicate start of dynamic 
VTIDTAB entries for the VTIDTABL (insert them before 
VTIDTAB macro with LAST=YES to delimit the table). 
A VTLVB macro with HALT=LUCUR added is required for 
all dynamic VTIDTAB entries - add to existing VTLVB 
pointed to by associated VTLSB, or if none, code a VTLVB 
and point to it via ULVB parameter on the VCT or VTLSB’s. 


Installation: Code DYNLUS=YES on the VCT macro. 

Revise the VTAM Network Table to define the dynamic 
LUNIT pool and dynamic VTIDTAB macros for static 
LUNITs to be changed in order to use the dynamic LU pool. 
Modify/add VTCSB and VTLSB parameters, as needed, and 
code/modify VTLVB macros to add the HALT=LUCUR 
parameter, where needed. See the sample DYNSAMP 
VTAM Network Table on SYMREL. 

Ensure LUCUR is included in the Intercomm linkedit. 
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2.2.6 Procs Revised to Use Hi-Level Assembler (HLASM) 


The following Intercomm-supplied JCL procedures which execute the Assembler 
have been revised for executing the Hi-Level Assembler (ASMA90) instead of Assembler 
H (IEV90): 


ASMPC, ASMOC, ASMPCL, ASMPCM, LIBEASM, LIBELINK, DEFSYM, SYMGEN. 


This is required for ESA and OS/390. See the COPYPROX job in Chapter 2 of the 
Installation Guide for unloading these procs from SYMREL to the Intercomm or system 
PROCLIB. The REGION size for assembly steps has been increased to 1M. The above 
procs which executed Assembler H have been renamed on SYMREL to ASMHPC, 
ASMHPCL, ASMHOC, ASMHPCM, LIBEHASM, LIBHLINK, DEFHSYM, SYMHGEN. 


Documentation Changes: Installation Guide 
Operating Reference Manual 


New External Options: AM and RM parameters for the EXEC statement to define 
AMODE and RMODE (default is 24) for the linkedit steps on 
ASMPCL and LIBELINK. 


Installation: See Installation Guide. 


2.2.6.1 Procs Revised to use the DFSMS Binder instead of the Linkage Editor 


The following Intercomm-supplied JCL procedures which execute the Linkage 
Editor have been revised to use the DFSMS Binder (execute LINKEDIT - alias name for 
IEVW/BLINK), and have a revised region size of 2M: 


ASMPCL, LIBELINK, LKEDP, LKEDT, LKEDE, LKEDO, COB2PCL,PLIXPCL. 


The link edit parameters are XREF, LIST, LET, MAP, NCAL. In addition, the LKEDE and 
LKEDO procs have the OVLY parameter - remove if not desired and either of these procs 
are used. Note that program objects on PDSE data sets are not supported. Because the 
input libraries from which modules are included are PDS data sets containing object or 
load modules, the Binder internally executes the linkage editor. However, the Binder 
produces more information in the SYSPRINT listing such as indicating from which library 
each module was copied. Use this data to verify the correct version of a module was 
included. To reduce the printed output, change the LIST parameter to LIST=STMT. 


The above procs may be internally changed on the user proc library to execute the 
linkage editor directly by changing the LKED EXEC statement to execute HEWLKED 
instead of LINKEDIT (do not change the LIST parameter). 


Documentation Changes: Operating Reference Manual 
Installation Guide 


New External Options: AM and RM parameters for EXEC statement to define 
AMODE and RMODE (default is 24) for the linkedit in 
ASMPCL, LIBELINK, and LKEDP. 


Installation: Copy procs to user proc library. 
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2.2./ High Thread Count Warning 


SYCT400 has been enhanced to provide an ALERT message MS333A to warn of 
a potential processing slowdown. The new message text is: 


*** ALERT *** - CONCURRENT THREAD COUNT IS NOW nnn. 


This message is issued when the concurrent thread count reaches a predefined 
threshold (default is 70) above the normal peak processing count. The threshold is 
defined via a new SPALIST macro parameter WARNHIT=nnn/70. The ALERT message 
will be reissued as the concurrent thread count continues to increase, and stops when the 
concurrent thread count starts to decrease. The time stamp on the message can be used 
to determine if external factors are affecting Intercomm throughput and then to correct the 
problem. The predefined threshold value in the SPA can be dynamically changed via a 
new option on the SCTL$SPA command called WARNHIT which is entered as 
SCTLSSPASWARNHIT=nnn. The maximum value for the WARNHIT SPALIST 
parameter, and for the command option, is 255 (maximum allowed concurrent subsystem 
threads). 


Note that this ALERT message may be issued (and repeated) if ESS or Basic 
sign-on Security is used when the system is brought up, or the VTAM Front End is 
restarted, during peak processing hours when many users are reconnecting to the 
system. Do not modify the WARNHIT value to account for this occurrence, as the 
message cause is known in this case, and this is a rare situation. 


Other causes for an unusually high thread count include: the resumption of 
subsystem processing after a full region snap is taken; when an IBM RESERVE is issued 
by/for a batch program against a disk pack containing online files; unscheduled batch 
processing against online files or data bases. 


Documentation Changes: system Control Commands 
Operating Reference Manual 


New External Options: SPALIST macro, WARNHIT=nnn/70 parameter. 
SCTLSSPASWARNHIT=nnn command. 

Installation: Automatic. 
Change WARNHIT parameter on SPALIST macro as 
desired. 
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2.2.8 Automated BMN Back-off Installation 


For existing users who reference the low-order 3 bytes of the old MSGHPID field, 
which is used for a 3-byte BMN number field under Releases 10 and 11, a BMN back-off 
option has been implemented. The backoff entails removing the label of the new BMN 
number field and restoring the label of the old Release 9 2-byte BMN number field (in 
Message Header COPY members), and reassembling modules which reference the BMN 
number field. 


This back-off installation is implemented via setting the new global &BMNOLD to 1 
in SETGLOBE (on SYMLIB) before assembly of the ICOMGEN macro for Release 11 
installation. A new Job 6 will be generated, which applies the Message Header change 
deck (CMSGHBMN on SYMREL) to the Message Header copy members and saves them 
on SYMLIB, and then reassembles affected modules which are not automatically 
reassembled in other installation jobs. 


The affected COPY members are MSGHDRC (can be copied directly, or copied 
when the MSGHDR macro is issued in Assembler code), ICOMDWS and ICOMINMG (for 
COBOL programs), and PLMSGHD and PL1HDR (for PL/1 programs). 


The modules reassembled in Job 6 are CONVERSE, FINTUNER, FORMGEN, 
LOGANE15, LOGPRINT, LOGPROC, MAPOUT (if MMU used), PAGEMSG (if Page 
Facility used), and QUEUEMOD (if BTAM terminal support used). 


Documentation Changes: Installation Guide 
Operating Reference Manual 
New External Options: &BMNOLD global in INTGLOBE/SETGLOBE. 
Installation: Automatic via ICOMGEN macro (if &BMNOLD global preset 


to 1 in SETGLOBE). 
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2.2.9 Multiregion Optimization and Multiple MRS Systems Support 


This enhancement optimizes Multiregion startup and provides for executing more 
than one Multiregion system in the same CPU (LPAR). Obsolete/unused code has been 
deleted from MRINTER (Multiregion startup/closedown), MRPURGE, and MRBATCH. 
The internal MRFIND macro (to find the MRMCT table in the Link Pack Area) used by 
STARTUP3, MRINTER, and MRBATCH has been modified to force a program check (via 
ISK 15,15) if the loaded MRMCT table does not look valid. This ISK will abend startup 
with a SOC1. Note that STARTUP3 does not issue the MRFIND macro if MRINTER is 
not in the linkedit (even if the SPA module was assembled with the MULTREG global set 
to 1 in SETGLOBE) and Multiregion processing is disabled. If the MRMCT is successfully 
loaded by MRSTART, then MRPURGE uses its saved address (MRMCT does not have to 
be reloaded). If an MRMCT table cannot be loaded by MRBATCH, an ISK 1,1 is issued 
to force an abend of the batch region. 


MRINTER has also been changed for the Control Region to automatically load 
PMIRDTOO (commonly used name of the Multiregion Region Descriptor Table) without 
issuing message RCOOE6R. If it cannot be loaded, then revised message RCQO7I giving 
the tried RDT table name is issued, followed by existing message RCOOGR to request the 
name (PMIRDTnn suffix) of the RDT table to be loaded. Therefore, if the default name of 
PMIRDTOO is not used, ensure that no RDT table with that name exists in any library in 
the Intercomm execution STEPLIB libraries. If an alternate PMIRDTnn is successfully 
loaded, new message RCOO3I ‘THE RDT USED BY THIS REGION IS NAMED 
PMIRDTnn’ is issued to indicate that the default PMIRDTQO is not being used. Otherwise, 
messages RCOO7/ and RCOOGR are reissued for trying a different suffix, if any. 


To provide for multiple Multiregion systems in the same LPAR, the internal 
MRFIND macro conditionally calls (via the CALLIF macro) a new user exit to provide a 
numeric suffix for the name of the MRMCTxx[x] table to be used by the calling system. 
To be called, the new user exit must be called UFINDMCT, and must be linked with each 
region (Control and ail Satellites) in the alternate Multiregion system. If the user exit is 
not present, the default name “MRMCT “~“ is used for loading, and enqueuing on, the 
table by the primary system. If MRBATCH is used with the alternate system, then 
UFINDMCT must also be linked with it. If the exit routine is present, and it adds a 2- or 3- 
digit suffix to the MRMCT table name, then that new name is used for loading, and 
enqueuing on, the alternate MRMCT table, which must be pre-coded and linked to the 
Link Pack Area with the new suffix added to the name. If the MRMCT name is modified, 
then new message RCOQ3l is issued by MRINTER (see above) giving the MCT name 
loaded by the region. In the Control Region, the Job name is used (instead of 
CONTROL) for all Intercomm messages having a region name. If an alternate MRMCT 
table is loaded by the Control Region, then the last 2 non-blank numbers of the name are 
used, by default, for loading the PMIRDTxx table to be used by the alternate Control 
Region. lf PMIRDTxx cannot be loaded, then message RCQOQ/7I is issued with the tried 
RDT table name, and is followed by message RCOOG6R to request the numeric suffix of 
the RDT table to be loaded. When successfully loaded, message RCOO3l is issued giving 
the loaded RDT table name. At startup of each alternate region, the user should verify 
the MCT and RDT (if Control Region) names used via the issued message(s) RCOO3I. 
See Section 2.4.1 on coding the UFINDMCT user exit and alternate tables, if desired. 


Documentation Changes: Multiregion Support Facility 
New External Options UFINDMCT user exit, if coded (see Section 2.4.1). 


Installation: Automatic via ICOMGEN. 
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2.3 


GENERAL SYSTEM IMPROVEMENTS 
Miscellaneous system improvements include: 


Closedown processing has been modified to ensure all messages currently in 
progress (except IMCD, but including those waiting on subsystem load) are 
finished for IMCD, and all messages in progress (except NRCD) and queued for 
processing are finished for NRCD. If closedown times out, no new messages are 
started. Also, if closedown is in progress, dynamically loaded subsystems which 
have been loaded below the 16M line are not put on the delete queue when no 
more messages are in progress except if space is needed. In addition, after 
closedown times out, loaded 24-Amode subsystems on the delete queue are 
immediately deleted if no messages are in progress and subsystems on the load 
queue are removed from the queue. To prevent closedown from hanging after a 
timeout because a subsystem or subroutine load or delete is in progress, 
closedown goes into a wait loop for such loads or deletes to complete. This allows 
the ASYNCLDR subtask to be detached and exit cleanly back to CLOSDWN3. 


Subsystem Controller (SYCT400) processing has been changed to add the 
following improvements: for subsystem load/delete processing during closedown 
(see above); to add an internal counter for the current thread count of started 
messages (also used for statistics reporting); to eliminate an ISK 4,0 if the current 
thread count is 255 (wait, and retry instead); to decrement the number of 
messages queued count (SPANMIP in the SPA) when a message is dequeued for 
processing (used by statistics reporting) rather than after it has completed; to 
delete obsolete MVS page preload processing (not needed): to prevent a SOC9 
in SAM (System Accounting and Measurement) processing when HIGHSTOR 
(high storage byte total) is being tracked, by starting tracking for a new thread 
before transferring ownership of the message to be processed to that thread; and 
to issue a high thread warning (see Section 2.2.7). 


CONVERSE has also been modified to prevent a SOC9 in SAM processing as for 
SYCT400 (see above). 


Processing of log buffer waits (when all log buffers full and being written to the 
Intercomm log) has been modified to ensure a thread timeout is disabled from 
purging until a call to queue a message (via COBPUT, MSGCOL, or FESEND) 
and/or a call to LOGPUT is completed. Processing in LOGPUT (to log a 
message) has also been optimized to reduce the chance of an ISK 5,5 in 
PMINQDEQ due to more than 255 INTENQ waits (on ‘LOGTAPE’) for a free log 
buffer. This improvement also reduces the chance of lost messages for queues 
and on the log when a backup in logging occurs. 


The number of messages per second that can be sent to the CPU Console 
(because the internal timed wait interval has decreased), has been increased to 
25 in CNTO1MOD and VT01MOD. 


A new parameter TLOOPTM=nnn/30 has been added to the SPALIST macro to 
define the maximum long duration code loop (or file OPEN wait) timeout (of the 
current thread) in seconds (default is 30) for ISKTLOOP processing. Thus, the 
timeout value can be different for each region, if desired. The minimum value is 2 
(seconds), and the maximum is 300 (5 minutes). In addition, the timeout message 
MPO20A has been modified to use the message-id prefix (SPALIST macro, 
WTOPFX parameter) and to give the name of the source region where issued. 
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® Recovery for a program check in PMISNAP1 or SPINOFF has been modified to 
ensure Timer Queue WQE'’s are updated and dispatched when they expire. 
STIMER processing has been optimized in PMISNAP1 and the Dispatcher 
(IJKDSPO1), and their interface with IXFDYALC (dynamic file 
allocation/deallocation command processing) and IJKTLOOP. 


8 Return and status codes have been added to the ‘RENAME FAILED’ error 
message MP018I from SPINOFF for easier debugging of the problem. 


8 For Multiregion users, the default on the SUBSYS macro for the IFDOWN 
parameter has been changed from QUEUE to FLUSH, and for the RESTART 
parameter from YES to NO. Also, LOG=NO (if coded) for the MROTPUT 
subsystem will now be recognized by LOGPUT. 


6 Log Analysis processing has been modified to increase the maximum terminal-ids 
to be processed on Intercomm log(s) from 5000 to 10,000 (to prevent message 
LAO10A and User Abend 10). 


® Message Collection (BLMSGCOL) processing has been modified to force a ‘queue 
full’ return code of 4, if the number of INTENQ waits on a subsystem or terminal 
disk queue reaches 255. This will prevent an unwanted ISK 5,5 (forced program 
check) in PMINQDEQ. 


@ STAEEXIT can be used in batch mode if linked with BATCHPAK (and user 
programs). 


® The default for the NUMWQES global in SETGLOBE (to give the number of WQE 
entries to generate for assembly of IJKDSP0O1) has been increased to 1000. 
However, the SCTLSDC$WQESS$FREE command will only display the last 105 
WQES on the free WQE queue. 


e ICOMLINK macro has been corrected to also generate includes for Multiregion 
modules (if requested) if the IISVC SVC instead of the MRSVC SVC is used. 


e The INTASMF_ supplied JCL procedure has been changed to _ specify 
INT. MODASMEF as the only library for STEPLIB, because the ASMF load modules 
must be relinked to a library which is MVS-authorized (recommended name is 
MODASMF). Also, the TAPE parameter has been changed to specify 3480 as the 
default (future SM’s will be supplied on tape cartridges, not mini-reels). 


Documentation Changes: Basic System Macros 
Messages and Codes 
Operating Reference Manual 
Multiregion Support Facility 


New External Options: SPALIST macro, TLOOPTM=nnn/30 parameter. 
SUBSYS macro parameter default changes: 
IFDOWN=QUEUE/FLUSH and RESTART=YES/NO 
LOG=NO may be coded for the MROTPUT subsystem 
(subsystem code 2). 


Installation: Automatic. Modify TLOOPTM and SUBSYS macro 
parameters, as desired. 
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2.4 USER EXIT CHANGES 


The following lists user exits for which calls (via CALLIF macro) have been added, 
or for which sample exit routines are supplied or processing changed: 


e UFINDMCT - new exit called by MRFIND macro in MRINTER (MRSTART), 
MRBATCH, and STARTUP3 to set the suffix (default is blanks) of the name of 
the MRMCT to be loaded by the region (if Multiregion Facility in use). 

e USTAEXIT - new exit called by STAEEXIT for user cleanup processing. 


e USRSTSCH - provided sample can be used to process generic Station Table 
CRT entries when EXTERM for a terminal-id fails to find a specific entry. 


e LUCUR - supplied HALT exit routine for VTAM Front End SPLU processing 


has been modified for dynamic LU support and if implemented, LUCUR must 
be included in the Intercomm linkedit. See Section 2.2.5. 
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2.4.1. UFINDMCT Multiregion Exit 


As described in Section 2.2.9, the Multiregion Support Facility has been enhanced 
to support more than one Multiregion system in one CPU (LPAR). The second (alternate) 
system will function independently of the primary (production) system. To install one (or 
more) alternate system(s), the three coding requirements are: 


1. Code the alternate MRMCT table (may be a copy of the primary MRMCT) containing 
an entry for the CONTROL region (must be first), and as many Satellite regions as 
desired, plus an entry at the end for a BATCH region (if it may be used). Assemble 
and link this new table to the system LPALIB (see Installation Guide) with the name 
MRMCTxx or MRMCTxxx, where xxx is a 2- or 3-digit number. The satellite region 
names should not be exactly the same as for the primary system, to distinguish the 
source of Intercomm Console messages with a region name from that of the primary 
system (also change the SPALIST macro, MRID parameter, in each Satellite Region 
to match). Or, the SPALIST parameter WTOPFX can be used in all alternate regions 
to distinguish their messages from those of the primary system. 


2. Code the alternate PMIRDTxx table (where xx matches the last 2 non-blank digits of 
the MRMCTxxx table name), and assemble and link it to a STEPLIB library for the 
alternate Control Region execution. If it is desired to use the primary system 
PMIRDTnn table, it is not necessary to make a copy (unless the STEPLIB libraries are 
different), but it is necessary to match the xx suffix of the alternate MRMCTxx table 
name to the nn suffix of the primary PMIRDT. That is, if using PMIRDTOO, name the 
alternate MCT table MRMCTOO. 


3. Code, assemble and link the user exit UFINDMCT to tell Intercomm startup the suffix 
of the alternate MCT table name. This user exit must be serially reusable (called by 
both STARTUP3 and MRINTER (MRSTART)), and have a local save area for saving 
and restoring the caller's registers. At entry, Register 1 contains the address of the 8- 
byte MRMCT default name (5-character MRMCT, followed by 3 blanks (X’404040’)). 
The user exit must modify the blank suffix to that of the MRMCT table name to be 
used for the alternate system, and return to the caller. This altered name will then be 
used by startup to LOAD the alternate MCT table (obtain it’s address in the LPA), and 
for MVS system-wide enqueues. 


ESS (Extended Security System) users must also code, assemble and link an 
alternate SECVECT table to the LPALIB (give it a 1-digit suffix to correspond to the 
alternate MRMCT name suffix). Then, modify STARTUP3 (if the IISVC is used) and 
INTSECOO to LOAD the alternate SECVEC Tx table. 


The installed IISVC or MRSVC can be used by each MRS system. 


Documentation Changes: Operating Reference Manual 
Multiregion:Support Facility 


New External Options: None. 


Installation: Code and include UFINDMCT with MRINTER in each region 
of the alternate MRS system, and with an alternate 
MRBATCH if used with the alternate system. Link alternate 
MRMCTxx[x] to system LPALIB. Add alternate PMIRDTxx, 
if desired, to an execution STEPLIB library. 
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2.4.2 USTAEXIT Exit for Abend Cleanup 


This new exit routine (must be user coded) is called by STAEEXIT for all non- 
recoverable system and user abends. It is called just before return to ESA (via SETRP 
macro) if the abend code is x22 (system cancel), or just before File Handler closedown if 
not an x22 abend. The exit routine must save and restore STAEEXIT’s registers, use a 
local save area, and may not directly (nor indirectly) give up control to the Dispatcher. 


At entry, register 2 contains the abend code (in hex). The low-order byte contains 
X'22’ if the abend is due to a system cancel. 


Documentation Changes Operating Reference Manual 
New External Options: None. 


Installation: Code user exit if desired, and include with STAEEXIT. 


2.4.3 USRSTSCH User Exit 


If Basic Security is not implemented, generic entries for input/output (CRT) 
terminals in the Station Table (PMISTATB) may be used in conjunction with this exit 
which is called by PMIEXTRM if an EXTERM fails to find a Station Table entry for the 
specified terminal name. As of Release 11, generic entries for CRT’s may be defined 
even if ESS (the Extended Security System) is used, as ESS processing no longer 
references the Station Table. Even if Basic Security is installed, generic names can be 
used for all, or groups of, printers (output-only devices). A supplied version of this exit 
processes for both CRI’s and printers, and can be modified for installation naming 
conventions. 


Documentation Changes: SNA Terminal Support Guide 


Operating Reference Manual 
Extended Security System 


New External Options: Modify supplied USRSTSCH for site, if desired. 


Installation: Include user-modified USRSTSCH in Intercomm linkedit. 
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2.5 DESUPPORTED FACILITIES 


The following are desupported because they are no longer applicable or are 
obsolete (see also list of deleted modules in Appendix A): 


e MVS/370 and MVS/XA operating system support 
e MVS/ESA support below level 4.3. 


e MVS Page preloading (PRELOAD parameter on RTNLINK macro ignored, 
LOADP macro, PMIPGLD and LOADPAGE modules deleted) 


e Model System Generator special feature (modules and macros deleted). 
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26 USER PROGRAM PROCESSING OPTIMIZATIONS 


The following enhancements represent processing optimization, and ease coding 
and maintenance, for user subsystems, subroutines, and batch mode routines: 


e Time Controlled Message Processing (see Operating Reference Manual) has 
been enhanced to provide for repetitive message generation (and queuing for 
the associated subsystem code) at the interval defined by the (previously 
unused) PRIN=nnn/OQ parameter on the TMZONE macro. The value coded 
for PRIN may be in the range of 1 to 255 minutes. If PRIN is coded, the 
SCHT parameter must be omitted. The first message is queued PRIN 
minutes after startup completes and is regenerated every PRIN minutes until 
closedown. 


e On the RTNLINK macro, the PRELOAD parameter is ignored, if coded. MVS 
Page preloading is no longer needed and not supported. 


e For Indicative Dump processing (see Operating Reference Manual), to reduce 
the size of the associated Snap ID=126, the INDUMP size coded on the 
SPALIST macro will be used for dynamically loaded reentrant COBOL 
subsystems if the load module size is greater, otherwise the load module size 
is used rather than the INDUMP size. For all user subroutines, use the load 
module size if dynamically loaded, else use the INDUMP size if resident. A 
called subroutine is snapped only if it is a resource (defined via the 
REENTSBS Table) in use by the application thread at the time of the snap. 


e For easier debugging (in MVS Save Area Trace in a snap), the down-chain 
word in the save/work area acquired by a SUBLINK macro is cleared so that 
an invalid save area is not snapped. Thus, no lower subroutine has been 
called if the down-chain field is zero at snap time. 


e For the SUBLINK macro, the save area size restriction of 4088 for the LEN 
parameter has been increased to 32760 (if coded as an EQUate or numeric 
value). Also, a value larger than 4088 does not have to be preloaded to a 
register on the RTNLINK macro if the same save/work area size is to be freed 
as was acquired by a previous LINKAGE or SUBLINK macro, that is, the LEN 
parameter is coded with the same value on each macro. 


e For Batch Mode processing, where an Assembler user program is linked with 
BATCHPAK, a PMIWTO macro with RENT=NO may be used (this support 
incorrectly deleted in Release 10), PMINQDEQ (for INTENQ/INTDEQ macro 
requests with the SYSTEM parameter) may now be linked before BATCHPAK 
(does not use the Dispatcher in Batch Mode), STORAGE macro issuers may 
use the LOC=ANY parameter to acquire 31-Amode (31-bit) storage and may 
enter BATCHPAK (which converts STORAGE to a GETMAIN) in 31-Amode, 
and STORFREE macro issuers must ensure the high-order byte of the 
address of 24-bit storage to be freed is zero but may also enter BATCHPAK 
in 31-Amode (which converts a STORFREE to a FREEMAIN). For the 
STORAGE and STORFREE entries in BATCHPAK, BATCHPAK returns in 
the Amode of the caller. 


Documentation Changes: Basic System Macros 
Operating Reference Manual 
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| 2./ VIRTUAL STORAGE CONSTRAINT RELIEF 
‘S To provide further virtual storage constraint relief for Intercomm systems, the 
following changes have been implemented: 


e Dynamic LU support to reduce the size of the VTAM Network Table by 50-75% 
(see Section 2.2.5). 


e The VTAM Front End internal VXQCB control block pool area (for VTAM 
System Exit routine request processing), which is acquired during VTAM 
startup, is now in GETMAINed 31-Amode storage. The SNMAX value on the 
VCT macro (or the number of LUNIT’s in the VTAM Network Table if SNMAX 
is O) is used to define the number of VXQCB pool blocks for acquiring the area 
(see also below). 


e The number of VRE (VTAM RPL plus VRE header) areas to acquire in 
GETMAINed 24-Amode storage for the Intercomm VTAM VREPOOL has been 
cut in half and is the value coded for the SNMAX parameter on the VCT macro 
(or the number of LUNIT’s if SNMAX is 0), plus the values coded for the 
RCVNO and RCVRSP parameters on the VCT macro. Therefore, if many of 
the LU’s log on for only a short period or only sporadically, it is advantageous 
to code the SNMAX value on the VCT macro for only the maximum expected 
concurrent sessions (successful Logons). See also Section 2.8 on the 
VTSTSTOT display change. 


e Generic entries for CRT’s may be defined in the Station Table, and managed 
via the USRSTSCH user exit, even if the Extended Security System (ESS) is 
nd used, as ESS no longer uses the Station Table CRT entries to hold the timeout 
WQE addresses. The address for each terminal has been moved to the ESS 
control area (in SQA) for the corresponding signed-on user. Therefore, the 
size of the Station Table may be greatly reduced. (See Section 2.4.3.) 


e The Page Facility will use the 31-Amode pools (if implemented), instead of 
GETMAINed storage, via the Table Facility (INTTABLE), to create the Master 
Page Table and to save individual CRT terminal responses (groups of 1 or 
more output messages). See Section 2.2.4. Note that for Release 10 at SM 
Level 2300, the Page Facility was redesigned to eliminate the user-coded 
Page Table and BDAM Page Data Sets (terminal responses saved in Page 
Response Tables via INTTABLE). 
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28 STATISTICS GATHERING AND SYSTEM DISPLAY/REPORT UPGRADES 


The following enhancements and changes have been made for system statistics 
printing and display modules: 


e A running current thread count is kept in the Subsystem Controller for easier 
statistics reporting (counting of assigned thread numbers no longer needed). 


e Processing of the backend ‘messages queued’ counter (SPANMIP in the SPA 
table) has been modified to just reflect the total messages queued for 
subsystems, and to not include messages currently dequeued for 
processing/flushing. 


e A thread count (HIGH/NOW) statistic line, a Back End Messages Lost (due to 
queue full) statistic line, and a Back End Messages Queued statistic line have 
been added to the System Tuning Statistics report on STSLOG. 


e BACK END MSGS LOST (Q FULL) and BACK END MESSAGES 
CANCELLED counts line has been added to the TALY$SU command display. 
Note that the counts are cumulative for the run (since startup). 


e For Multiregion systems, a Number of Dynamic CSA GETMAIN’s statistic line 
has been added to the Multiregion statistics portion of System Tuning 
Statistics for each Multiregion region. This statistic indicates whether the 
MRCSALN parameter on the SPALIST macro for Satellite Regions or the 
CSALEN parameter on the REGION macros in the PMIRDT table define large 
enough areas of CSA storage (for cross-region message transfer) for the 
associated regions. Only one message is transferred at a time, therefore this 
statistic represents the number of times a larger (than the area acquired for 
message transfer at startup) message was transferred. If the reported value 
keeps going up throughout a 24-hour period or during peak processing hours, 
increase the corresponding startup length request in 4K (MVS _ page) 
increments, as needed. 


e An ALERT warning message has been added to the Subsystem Controller to 
indicate a potential system slowdown because the current thread count is 
higher than normal peak processing (see Section 2.2.7). 


e TDUMP (Thread Resource RCB reporting) and SAM (System Accounting and 
Measurement) statistics gathering processing now support 8-digit numbers for 
storage acquisition and totals counts and for reporting of those values. 


e If HIGHSTOR is specified on the MAPACCT macro defining the desired 
statistics, SAM statistics gathering has been corrected to prevent a SOC9 due 
to a negative storage count bucket during the offline report generation. During 
SAM online total storage processing, an ISK 2,0 is issued if the HIGHSTOR 
bucket goes negative (indicates storage acquired by the system thread 0 is 
being freed by an application non-zero thread which did not previously use the 
CATCH macro to acquire ownership of the storage or use the SYS=YES 
parameter on the STORFREE macro - see also the description of message 
RM033! in Messages and Codes). In addition, the STORAGES counter is 
incremented to account for the input message to a subsystem. 
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lf SEQNO=BTAM is not coded on the VCT macro for the VTAM Front End, 
then for BMN number reporting (TALY$SU display and System Tuning 
Statistics), a running input message total count is internally kept (SEXBMN# 
field in SPAEXT table) in single-region systems and the Control Region of a 
Multiregion system. This value is then used for the reports (if SEQNO=BTAM, 
then the count in the BTSPA control block (incremented by BTAM and VTAM 
Front Ends) is used. In Multiregion Satellite Regions, the SEXBMN# field is 
changed to the BMN number of each input message to the region, and used 
for reporting. If SEQNO=BTAM is not used in the corresponding Control 
Region, then this number is meaningless, and should be ignored in the 
Satellite Region reports. 


For the File Handler Statistics report on SYSPRINT, a FILE TYPE column has 
been added next to the DDNAME column. File types reported are PS (PSAM, 
SYSIN, and SYSOUT files), ISAM, BDAM (relative record number access), 
BDAM-K (keyed access), and for VSAM files: KSDS, ESDS, or RRDS 
(depending on file access type). If the file type is unknown (should not occur), 
the type is listed as ‘7???’ 


Storage Management Core Use Statistics on SMLOG have been enhanced for 
31-Amode storage requests and the 31-Amode storage pools (if implemented). 
See Section 2.2.4. 


The DISTRIBUTION OF CORE BLOCK SIZES section of the Core Use 
Statistics (if COREACCT macro coded in the pools modules) report on 
SMLOG omits lines for size ranges for which no storage requests have been 
made. Therefore, this section will grow longer as the system run time 
increases and more different sizes are requested. Use an end of the day, or 
run, report for tuning the pools modules. 


Thread Dumps (Thread Resource Report) on SMLOG will show ICOM in the 
S/P NO. column for 31-bit storage addresses acquired from the 31-Amode 
pools, if implemented (otherwise the GETMAINed storage subpool number - 
usually 000 - is given). 


The POOLDUMP-generated STATUS OF INTERCOMM ADMINISTERED 
STORAGE report on SMLOG (if POOLDUMP in the linkedit - see Operating 
Reference Manual) has been optimized to reduce the number of printed lines 
(60 per page) and modified to also report on 31-Amode pool blocks (see also 
Section 2.2.4). POOLDUMP will recognize (does not program check) an 
invalid pool block header (see Section 2.2.3) and will print the header in Hex if 
no RCB can be found for the block’s area. Date/time stamp has been added 
to the header. 


The VTST$TOT command display (of VTAM statistics totals) has been 
modified to also show the HIGH number of concurrent sessions (successful 
logons) since startup. When displayed late in the day after the daily peak 
processing time, this statistic can be used for tuning the maximum sessions 
allowed via the SNMAX parameter on the VCT macro. Allow for about 200 
extra sessions for logons at the end of the month, or whenever the monthly or 
annual peak processing occurs. Note that the current SNMAX parameter 
value (shown as MAX ALLOWED in the VTSTS$TOT display) can be 
dynamically changed for the current run via the VTCN command (see System 
Control Commands). 
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The VTST$TOT command processing has also been modified to display a 
second line giving statistics for Dynamic LU usage (if implemented), as 
follows: 


DYNAMIC LUNITS: CONNECTED=n IN USE=n MAX USED=n DEFINED=n. 


Where n is a number from 0 to 9999, as applicable. Note that the MAX USED 
number of ‘in use’ dynamic LU’s may exceed the HIGH sessions on the VTAM 
sessions totals line, due to dynamic LU’s (for printers) assigned from the pool, 
but never successfully connected (logged on) because the SIMLOGON failed 
or was cancelled by VTAM (see Section 2.9 on enhanced NSEXIT 
processing). The MAX USED (maximum concurrently assigned DLU’s) number 
can be used to tune the maximum number of Dynamic LU’s required in the 
DLU pool (plus a fudge factor of 200-500 LU’s for peak processing). 


On-line and utility report programs have been updated to have a 4-digit year in 


the date on the heading line (see Section 2.2.1). 


Documentation Changes: SNA Terminal Support Guide 


system Control Commands 
Messages and Codes 
Operating Reference Manual 
Multiregion Support Facility 


New External Options: None. 


Installation: 


Automatic. 


2-26 


Chapter 2 Release 11 Features 


2.9 VTAM FRONT END CHANGES 
The following changes and enhancements have been made for VTAM support: 


e The VXQCB area for VTAM system exit processing has been moved above the 16M 
line and the size of the VREPOOL (VTAM RPL’s) acquired at startup has been 
reduced (see Section 2.7). 


e For the VTERR macro with ID=76 (RECEIVE processing logic error in VTRECVE), the 
EXIT parameter has been changed from VTCN (bring down the VTAM Front End) to 
EXIT=SPLU (just SPLU the associated LU). Also, only an indicative Snap ID=62 is 
produced instead of a full region Snap ID=63. See the description of message 


VTO25I in Messages and Codes. 


e lf the control terminal is the CPU Console, and it is defined via an LUNIT in the VTAM 
Network Table, the system is not abended at startup if a VITAM ACB OPEN failure is 
correctable. Instead, new message VT037R (VTAM STARTUP FAILURE WHILE IN 
STARTUP - ACB OPEN ERROR PROBABLE - REPLY ‘START’, ‘ABEND’, OR 
‘CONT?) is issued via VTAUTOUP (must be included in the linkedit). This message 
allows the system administrator to reply START (VTAM Front End), ABEND (the 
system), or CONT (without the VTAM Front End) when the problem is resolved (if 
possible). Meanwhile, the CPU Console (control terminal) is activated and the rest of 
system startup completes. If VTAUTOUP is not in the link, or the CPU Console is 
defined as a BITAM terminal, or if CONT is the response (to message VT037R), then 
the VTCN$SSTART command must be issued via the CPU Console to restart the 
VTAM Front End. Note that the APPLID option on the VTICN$START command can 
be used to provide a different (or corrected) VTAM APPLID for retrying the open of 
the VTAM ACB. If the new OPEN is successful, correct the APPLID parameter coded 
on the VCT macro in the VTAM Network Table for future system startups, if 
appropriate. 


e  VTAM Front End restart will try to acquire (via SIMLOGON) all ‘shared’ printers 
(output-only devices) with queued messages (even if ACQ=YES was not originally 
coded on the LUNIT), including all qualifying assigned ‘dynamic’ LUNIT’s. 


e New Origin Code 1E00 has been added for the VTAM FC1211 (LU DISCONNECTED) 
message indicating the SPLU originated from VTURSDX1 due to a (earlier) RELREQ 
request (SPLU occurs after all queued messages are sent or flushed). Also, Origin 
Code 0400 has been added for this message if the SPLU is due to VTAM SCIP Exit 
processing. See the VIAM Origin Codes table for VTAM Messages FC100I-FC150! 
in Messages and Codes. 


e The Multiregion MRPASSW parameter can now be coded on a VICSB macro shared 
by all input terminals to be locked to a particular Satellite Region at logon. It is no 
longer necessary to code it on each LUNIT for which RAP processing is desired. As 
before, the terminal can be dynamically unlocked, or locked to a different region, after 
logon. However, for the next logon, the defined MRPASSW region locking will occur. 
VTST and WHOI/WHOU command processors have been corrected to display the 
current locked-to region name (if any) after logon, or the original defined region name 
(if any) when not logged on. 


e General FECMDDQ processing has been corrected to handle DDQ access error 
processing, and DDQ close processing conflicts. 
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e Message flushing logic has been corrected to include a rescheduled message (if any) 
in the count, and to correct counting for FECMDDQ processing. 


e For the CPU Console defined as a VTAM LUNIT, message flushing (and DDQ 
processing, if any) logic has been corrected in VTO1MOD. 


e Pacing of Logon (and other VTAM System Exit routines) processing in VTEXITS can 
now be controlled to prevent bottlenecks and allow more overlap with other 
processing (including logging) in the system (Control Region). This pacing is 
particularly needed for a mid-day startup (or failure, then restart) of the VTAM Front 
End. Pacing is defined via a new VCT macro parameter XPACE=nnn (default is 100), 
which gives the number of Exit routine threads that can be dispatched by VTEXMAIN 
in VTEXITS before control is temporarily released to the Dispatcher to process those 
(and other ready) threads. A value up to 32767 (or the maximum Dispatcher WQE’s 
available less several hundred for other processing) can be defined. A value less 
than 50 is not recommended. This value can be dynamically modified via the 
VTCN$XPACESnnnnn command. 


e BID (to begin a Bracket) failure recovery is now provided for non-CRT SNA devices 
after the message VT010I is issued for a SEND (REQ=22) request with RTNCD=04, 
FDBK2=04, and SENSE=08130000. VTSEND will then retry the BID (error message 
repeated if it fails again). An internal RSLU to resync the device is issued before the 
retry. If the BID fails again, then the LU is SPLU’d and message VT025I with new 
ID=64 and a Snap ID=62 is issued. If the SPLU’d LU is defined as a shared printer, 
then after a new message is queued and a successful SIMLOGON to reacquire the 
printer occurs, the BID process is restarted. If the failure recurs, the cause should be 
investigated (may be a BSC device defined to VIAM and Intercomm as an SNA 
device, or local and remote VTAM definitions do not match). Meanwhile, deactivate 
the LU (SPLU$....sDEACT command) to prevent more error messages. 


e VTAM NSEXIT processing (in VTEXITS) has been enhanced to also recognize 
cancellation (NOTIFY RU sent by VTAM) of a pending SIMLOGON to acquire an LU. 
Such cancellation (after SIMLOGON initially accepted by the local VTAM) usually 
occurs due to a PATH error (LU’s VTAM-id not recognized or rejected on the remote 
end) or VARY INACT (CPU System Operator command) of the LU (local or remote). 
The resulting SPLU origin code is 1400 on message FC121] (LU DISCONNECTED). 
This new exit processing precludes the need for CPU Console operator (Control 
terminal) intervention to be able to issue a new STLU for the terminal. 


e After SPLU completion, NSEXIT and SCIP UNBIND exit processing will also call 
VTAUTOUP (as for the LOSTERM exit) to try reacquiring the LU (if an UPINTV and 
ACQ=YES was coded for the static LUNIT, and it is still active to accept a Logon). 


e LOSTERM, NSEXIT, and SCIP dispatched VTAM Exit processing in VTEXITS has 
been modified to ignore the request if a VTAM Front End SHUTD or HALT is in 
progress, or if the VTAM ACB is already closed. LOGON Exit processing has been 
modified to reject the logon if the ACB was closed before the dispatched logon routine 
could be processed. 
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VTAUTOUP has been modified to prevent a dispatch of itself (if VTUPINTV coded on 
the VCT macro) if a WTOR has been issued to provide for a dynamic restart of the 
VTAM Front End (see the description of messages VT031R, VT032R, and VTO36R in 
Messages and Codes, and of new message VT037R above). Prevention of the 
dispatch also occurs by testing if a system closedown/abend is in progress, or it has 
already dispatched itself. In addition, the dispatched (if a VTUPINTV given) entry 
tests again if a system closedown/abend has occurred since the dispatch, and if so, it 
exits. 


A new VCT macro parameter, MAXLGONF=nnn (default is 0, maximum is 255), has 
been added to enable forcing an internal SPLU$...SHALTS$DEACT of an LU (shared 
printer) after nnn SIMLOGON attempts to acquire the LU have failed (due to device 
not plugged in, or incorrectly defined, or otherwise not available). When an LU is 
deactivated, new SIMLOGON attempts to acquire that LU are prevented (even if new 
messages are queued for a shared printer). A running count is kept in each LU 
contro! block (LUB), and is copied to the dynamic VTIDTAB entry (if Dynamic LU’s are 
implemented) when a dynamic LU is unassigned. The count in the dynamic VIIDTAB 
entry is then recopied to a newly assigned dynamic LU, if the dynamic VTIDTAB entry 
has not yet been deactivated. Note that a SPLU$...S5DEACT (internal or external) of a 
dynamic LU will cause the corresponding dynamic VTIDTAB entry to be deactivated 
when the DLU is unassigned (and the now available DLU is reset to active status). 
(See also new DEACT option of VTIST command in Section 2.10.) The LU (dynamic 
VTIDTAB entry) may be reactivated via a STLU command after the problem is fixed (if 
possible). If a successful LOGON occurs (problem was transient) before an LU 
counter reached the MAXLGONF non-zero value, then that LU’s counter is reset to 0. 
New message FC144l (o000-LU xxxxx DEACTIVATED - MAX ALLOWED 
CONSECUTIVE SIMLOGON FAILURES HAVE OCCURRED) is issued when an LU is 
internally deactivated. Defining a reasonable MAXLGONF value precludes the 
necessity for system operator/manager intervention (to SPLUS...SDEACT an LU) 
when acquire (SIMLOGON) failures occur (and also reduces the number of repetitive 
error messages issued to the Control Terminal). MAXLGONF may be dynamically set 
or modified via the VTICN$LGONF$nnn command. The maximum accepted value for 
nnn is 255. 


VTERRMOD (internal VTERR macro/message VT025I processing) has been modified 
to ensure the passed VRE (RPL) area is freed on a VTERR condition (after message 
VT025I and Snap issued), if the associated LU is to be SPLU’d or the VTAM Front 
End is to be shut down. This wiil help speed up VTAM closedown. VTERRMOD has 
also been modified to check if a VTAM Front End closedown is in progress or the ACB 
is closed, and if so, do not dispatch local entry ASYNTHRD to process a SPLU (of LU 
in error) or VTCN (HALT of VTAM Front End) option if requested via the EXIT 
parameter of the VTERR macro. In the dispatched ASYNTHRD routine, it will exit 
immediately if a VTAM Front End closedown has been started or has occurred. 


Documentation Changes: SNA Terminal Support Guide 


system Control Commands 
Messages and Codes 


New External Options: see above. 


Installation: Automatic (add/modify new parameters as desired). 
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2.10 SYSTEM CONTROL COMMAND ENHANCEMENTS 


The following system control commands displays have been revised, or new 


options have been added: 


TALY 


SCTL 


SU display gives the BMN number from the BTAM sequence number or the 
internal SEXBMN# counter as described in Section 2.82. BACKEND MSGS 
LOST (Q FULL) and BACK END MESSAGES CANCELLED counts display line 
added. 


The display date (with a 4-digit year) has been added to the TIME IS ... trailer 
line. 


An error message is returned if no parameter option is entered (too many 
screens (output messages) are generated). 


For Front End Messages Queued displays, the count of messages queued for a 
VTAM LU has been corrected to include the current message being sent 
(awaiting a VTAM Definite Response), and a rescheduled (after SEND error or 
SPLU of LU) message, and a FECMDDQ message (if DDQ being processed). 
Note that the count does not include messages to be sent in the DDQ (nor one 
being sent from the DDQ - redundent). 


For displays of VTAM LU’s, the NUMBER (of LCOMP’s) ACTIVE column and 
total now show the correct counts. 


For displays of VTAM LU’s, the STATUS designation has been enhanced to add 
the following condition: LGON PENDING (indicates SIMLOGON has been 
issued, but logon has not yet completed). If the LU is an assigned Dynamic LU, 
the following potential STATUS conditions have been added: SPLU TIMEOUT 
(dynamic LU assigned for a printer has been SPLU'd, and it is now in a timeout 
with messages to send and awaiting a new STLU attempt or a flush (dynamic or 
after timeout) of the messages so the DLU can be unassigned); LOGON 
FAILED (indicates Dynamic LU assigned for a printer for which at least one 
SIMLOGON was issued, but was rejected by VTAM - LU is in a timeout state). If 
the LU is an unassigned Dynamic LU (cannot have queued messages), it is 


indicate it is part of a dynamic LU pool for LU6.2 processing). 


TDUMP$nnn display/report for a specific thread number now supports 8-digit 
numbers for storage acquisition and totals counts. The heading line now gives a 
4-digit year. 


SPASSTOCORE= value increased to 4 digits so that more than 1M may be 
requested (as ssss in K - kilobytes). The maximum allowed value has been 
increased from 999 (K) to 4096 (K) which is 4M (megabytes). 

WQESSFREE option displays only a maximum of the last 105 free Q WQES. 

A WARNHIT=nnn option has been added to the SPA parameter as described in 


Section 2.2.7 for dynamically modifying the concurrent thread count threshold at 
which an ALERT message should be issued to indicate a system slowdown. 
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FTUN 
SSUP 


VTCN 


WHOI 
WHOU 


WHOU 


VTST 


Processing corrected for changing MNCL for a dynamically loadable subsystem 
to prevent a tight code loop if the subsystem is not currently loaded. The code 
loop (introduced by SM 2180) occurred if MONOVLY (for Overlay B/C/D 
subsystem processing) was not in the linkedit (was not used). 


XPACE$nnnnn parameter added as described in Section 2.9 for dynamically 
modifying the pacing of VTAM Exit Routine process dispatching in VTEXITS. 


LGONF$nnn parameter added as described in Section 2.9 for dynamically 
modifying the threshold at which an acquirable (via SIMLOGON) LU (shared 
printer) is deactivated after nnn consecutive SIMLOGON failures have occurred. 


Display of the region to which an LU is locked has been corrected as described 
in Section 2.9 for coding the MRPASSW parameter on the VITCSB macro. 


The ‘LOGICAL ADDRESS vvvvvwvvwv’ (VTAN-id) is set to *DYNAMIC to indicate 
an unassigned Dynamic LU display (when appropriate). 


lf display for an unassigned Dynamic VTIDTAB entry is requested, it is treated 
as a Static LU that is not logged on (data taken from the entry and associated 
VTLSB and VTCSB macro coding). To indicate that the VTIDTAB entry was 
used, the line ‘vwwwwvww IS A DYNAMIC VTAMID WHICH IS NOT LOGGED ON’ 
is added at the bottom of the display. 


Unassigned Dynamic LU’s are omitted from general displays, but can be 
displayed individually (LUxxxxx parameter), if desired. 


Display of the region to which an LU is locked has been corrected as described 
in Section 2.9 for coding the MRPASSW parameter on the VTCSB macro. 


SIM parameter display has been corrected to no longer erroneously include the 
CPU Console (if defined via a VTAM LUNIT). 


DEACT parameter has been added (no sub-options) to list only deactivated 
(ineligible for LOGON/SIMLOGON) LU’s (static and dynamic, if any). Also, 
dynamic VTIDTAB entries (if any) which have been deactivated are listed if they 
are not currently assigned to a dynamic LU (if implemented). 


TOT display (and total line displayed at the end of a group display) has been 
changed as described in Section 2.8 to add the HIGH sessions count for the run. 
Also, a Dynamic LU'’s statistics/status line is added (if DLU processing 
implemented) to the totals display (as described at the end of Section 2.8). 


Documentation Changes: SNA Terminal Support Guide 


system Control Commands 


New External Options: see above. 


Installation: Automatic. 
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2.11 ESS (EXTENDED SECURITY SYSTEM) ENHANCEMENTS 
The following enhancements have been made to ESS processing: 


e Revise INTSECO2 to provide more base register relief (needed also for Year 
2000 enhancements) - review placements of user modifications, if any. 


e Revise ESS timeout processing to use the in-core sign-on control block to hold 
the timeout WQE address, rather than the Station Table. This eliminates ESS 
references to the Station Table, and thus allows generic entries in the Station 
Table for CRT's (see also Section 2.4.3). 


e Revise INTVRBOO processing, when ESS is used, to handle an exempt 
terminal (such as the CPU Console) which is locked to a verb and enters a 5- 
character data field. Do not treat this field as a terminal-id for fast message 
switch (resulting in an error (invalid terminal-id) and return of the ESS sign-on 
screen to the exempt terminal). 


e Revise IGCICSVC (for IISVC Intercomm Integrity SVC processing) load 
module to allow protected core requests up to 512K (from 256K). This may be 
needed for the ESS in-core user-id table when many users are defined in the 
security file. To use this change, reinstall IGCICSVC (see Installation Guide). 


e Revise ESS modules for 4-digit year: fix displays, account/password expiration 
date, report dates, and replace GETDATE (uses CVTDATE) with INTTIME 
(on-line): INTSECO2, SECUEXIT, SECUPRNT. Also fix editing/converting of 
time fields. 


e In INTSECO2, revise EXPDT attribute for 4-digit year: to provide for specifying 
an account/password expiration date after the millenium, the EXPDT(yyddd) 
attribute definition has been changed to EXPDT(yyyyddd). 


e Resequence SECUEXIT to facilitate insertion of user modifications - review 
modification sequence numbering, and date field references for 4-digit years. 


e Modify ESS SECUPTRS utility: add FIXDATE option for one-time conversion 
of 2-digit year fields to 4-digit year (change packed date fields, if initialized, to 
have leading century digits - convert from OOyyddds to ccyyddds), and convert 
time fields for easier internal use and external display. Print converted user 
record fields. 


Documentation Changes: Extended Security System 


New External Options: FIXDATE parameter for executing SECUPTRS to convert 
the SECURITY file for 4-digit year processing. 


Installation: *** WARNING FOR ESS USERS *** 
Do not use the Release 11 INTVRBOO, INTSECOO, 
INTSECO2, SECUEXIT, or SECUPRNT in production until 
all of the following steps have been taken: 
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Chapter 2 


Release 11 Features 


1) Use the SECFILE Utility to copy the production ESS file. 

2) Run R10 SECUPRNT Utility to print the entire copied 
file. 

3) If not already done, run R10 or R11 SECUPTRS Utility 
against the copied file with PARM=’UPDATE’ to provide 
user account record back-chaining for on-line delete 
processing. 

4) Run R11 SECUPTRS Utility against the copied file with 
the new PARM='FIXDATE’ to fix non-zero date and time 
fields as described above. 

5) Run R11 SECUPRNT Utility against the updated (by 
FIXDATE parameter for the SECUPTRS Utility) file to 
reprint the entire file. 

6) Compare the Security file printouts from steps 2, 4, and 
5 to verify that the file was correctly fixed for 4-digit 
years in the date fields, and to verify time fields, where 
those fields were originally non-zero. 

7) Change the system (Control Region) JCL to ensure the 
DD statement for SECURITY is pointing to the updated 
file. Optionally do this in a Test system first, before 
changing the production system. 

8) Revise the R10 INTSECO2 and SECUEXIT user 

modifications for R11, as needed, and apply them to the 

R11 versions. Reassemble and link together the 

(modified) R11 INTSECO2 and SECUEXIT and place the 

new load module in a STEPLIB library for on-line system 

execution (before any library containing the R10 
version). Relink Intercomm with the R11 INTVRBOO and 
start the R11 Intercomm system (Control Region). 

Verify date/time fields in the sign-on response display (to 

ensure updated Security file being used with R11 

INTSECO2). 

10) Use the SECUSDISPLAYS$ACCOUNT$user-id command 
to display various users to verify R11 versions of 
date/time fields are being shown. 
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If initially tested in the Test system, relink the new 
INTSECO2 load module to the Production system STEPLIB 
library and change the DD statement for SECURITY to point 
to the updated (by SECUPTRS) file in the Production JCL 
and relink production Intercomm with the R11 INTVRBOO 
and INTSECOO for the next system startup. 


Warn your Security Managers of the date display changes 
and the EXPDT(yyyyddd) attribute change (if used). 


Chapter 3 


NEW DOCUMENTATION 


All of the Intercomm documentation is being updated to correspond to Release 11, 
where applicable. The following manuals have or will have SPRs or new editions: 


e ASME Users Guide -- New Edition (with first SM’s) 
e Assembler Language Programmers Guide -- New Edition 
e Basic System Macros -- New Edition - 7/98 

e COBOL Programmers Guide -- New Edition 

e Concepts and Facilities -- New Edition 

e Dynamic Data Queuing Facility -- New Edition 

e Extended Security System -- New Edition 

e File Recovery Users Guide — New Edition 

e Installation Guide -- New Edition - 6/98 

e Messages and Codes -- New Edition or SPR 

e Multiregion Support Facility -- New Edition 

e Operating Reference Manual -- New Edition 

e Planning Guide -- New Edition - 5/98 

e SNA Terminal Support Guide -- New Edition or SPR 
e System Control Commands — New Edition - 8/98 


e Table Facility --SPR 


Interim separate documents for the following new features will be provided with 
the Release 11 tape, giving a detailed description and installation/usage notes: Storage 


Management Enhancements and Dynamic LU Support. 


Some manual updates will be mailed with the Release 11 installation tape. The 
rest will be published when ready. New/revised indexes to the above manuals are being 
prepared, where necessary. Manuals not listed above have been recently updated (see 
the latest Publications Price List/Order Form) and require no new updates, or will not be 
updated because the feature is no longer generally used. 
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Appendix A 


INTERCOMM MODULES ADDED/DELETED/REVISED FOR RELEASE 11 


Added: 

IC31PL00 TRAP31 VTIDTABD (Dsect) 
DYNSAMP CMSGHBMN (BMN-back-off change deck) 
ASMHOC ASMHPC ASMHPCL 
ASMHPCM LIBEHASM LIBHLINK 
DEFHSYM SYMHGEN 

Deleted: 

LOADP LOADPAGE PMIPGLD SPLEVEL (IBM Macro) 
BLOCKA BLOCKAD BLOCKAW BLOCKB 
BLOCKBD BLOCKBW BLOCKC BLOCKCD 
BLOCKCW COBOLGN GENERTRN INTVL 
IRANGE RANDU RANDV TRANGEN 
Revised and/or Rewritten/Resequenced: 

MANAGER RMTRACE POOLDUMP TRAP 
POOLSTRT RMPURGE RMDSECTS SPALIST 
GETDATE INTTIME PMIDATER STARTUP3 
INTSTS LOGPUT RPTOQ0045 TALLY 
INTSECO2 SECUEXIT SECUPRNT SECUPTRS 
BATCHPAK BTAMSIM CLOSDWN3 IJKDSP01 
ICOMFEOF LOGPRINT PMISNAP'1 TRIGGER 
MRBATCH MRINTER MRMOD MRPURGE 
FEWHOI FECMD FESEND FEMSG 
INTVRBOO LUCUR PMIEXTRM LCOMP 
LUNIT LUDSECTS VCT VTIDTAB 
VTAMSTAT VTAUTOUP VTCDM2 VTEXITS 
VTLUCMD VTQMOD VTRECVE VTSEND 
VTSTART VTURSDX1 VTVREERR VTO01MOD 


Note: Many others have small changes. Csects which have changes for Release 11 
have DC X’11000000' as the next to last statement. 


Changed lines in Dsects, Macros, copy code, and Csects have ‘R11-xx’ (Release 
11 change) or ‘XMOnnn’ (where nnn is in the range 871-919 indicating R10 
Experimental SM nnn incorporated), where possible, starting in column 66. 
Changed lines for the Dynamic LU enhancement have ‘90xx’ starting in column 68. 
User mods to all modules must be carefully evaluated for applicability and 
necessity. 


Appendix B 


Intercomm Message Header Layout 


Field Name Length ° Legend* 
binary number 
MSGHQPR 1 Teleprocessing segment I/O code: 
00/FO=header segment; 
01/F1=intermediate segment; 
03/F3=final (trailer) seq 
Low-order receiving subsystem code 
|MSGHSSC__[__1_—i| Low-ordersending subsystemcode | SOM 
Monitor message number assigned by 
Message Collection (bina 


02/F2=full message; 
MSGHRSCH High-order receiving subsystem code 
MSGHDAT | 6 __| Julian date (YY.DDD | oN | 


|MSGHTIM__| 8 __| Time stamp (HHMMSSTH LN, = 
aa Terminal identification Y 

(originating terminal on input messages/ 

destination terminal on output) 

or Broadcast Group 

[MSGHFLGS_ | 2 _|Messageindicatorflags | CNC 
[(MSGHPID) | 2  |Reservedarea— — —“*‘CSC*irLS ON 
Front End message number (binary) - R10/11 
|MSGHSSCH [| 1 __| High-ordersending subsystemcode | SO MC 
User/system processing code 
a eer 

by the Front End (MSGHBMN - R9 


MSGHBLK/ 1 Reserved area/ 
MSGHMRDX/ Multiregion region number (log code 01/30)/ 
MSGHRETN Subsystem return code (log code FA/FD 


MSGHVMI 1 Verb or message identifier interpreted by Y 
receiving subsystem as required, 
and by FESEND 


*Alter Legend - see Operating Reference Manual, Appendix B. 


